home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / ietf / 92mar / wais-minutes-92mar.txt < prev    next >
Encoding:
Text File  |  1993-02-17  |  11.2 KB  |  287 lines
  1. This is only a rough draft - Megan 04/16/92
  2.  
  3.                       WAIS-W3-X.500 BOF MINUTES
  4.                                   
  5.  
  6.    BOF at the March 1992 IETF[1] , on the evening of March 18.
  7.    
  8.  
  9. Summary
  10.  
  11.    This meeting followed discussion at the "living documents" BOF[2]
  12.    the previous evening, and was more focussed in its discussion.
  13.    
  14.  
  15.    The WAIS, World-Wide Web, Prospero systems for network information
  16.    retrieval (NIR) were presented (the Gopher protocol was presented
  17.    in plenary the following day).  The x500 directory was presented
  18.    in the light of NIR needs, as were two proposals to use the
  19.    directory to refer to documents. A discussion followed as to how
  20.    to allow these systems to inter-operate, and on requirements for
  21.    name spaces. A working group was proposed to define the format for
  22.    a generalized printable format for a name or address in any of
  23.    these systems.
  24.    
  25.  
  26.   Chair                   Steve Kille, UCL and  ISODE consortium
  27.                          
  28.  
  29.   Present                 See list ietf-wwx-bof@info.cern.ch[3] .
  30.                          
  31.  
  32.    These minutes are available in hypertext form using WWW as
  33.    http://info.cern.ch./hypertext/Conferences/IETF92/WWX_BOF_
  34.    mins.html as well as through the normal channels.
  35.    
  36.  
  37. WAIS
  38.  
  39.    John Curran of BBN presented the WAIS protocol, in the absence of
  40.    anyone from Thinking Machines Corporation who were originally
  41.    responsible for it.  The WAIS model is of a number of servers,
  42.    each of which serves a number of databases, each of which contains
  43.    a number of documents.  Client software allows many databases to
  44.    be searched at the same time.  The server keeps an inverted full
  45.    text index for each database, so the search is very fast.
  46.    Non-text files may also be served: recent extensions allow
  47.    indexing of text files in new formats.  The files indexed need not
  48.    be copied, but the index is of the same order of size as the
  49.    files.
  50.    
  51.  
  52.    Many databases exist, but there is no scalable way of finding them
  53.    (TMC currently keeps a master index). Use of x500 was discussed.
  54.    
  55.  
  56.    The WAIS protocol is an extended subset of Z3950. The differences
  57.    were discussed:  WAIS allows relevance feedback ("Give me a
  58.    document like this one") , and  specifies how a query should be
  59.    formulated.  WAIS and Z39.50 have the same presentation layer.
  60.    
  61.  
  62. Documents in the Directory
  63.  
  64.    Wengiyk Yeongpresented his paper OSI-DS-22, "Representing public
  65.    archives in the directory"[4]. His project puts information about
  66.    documents, including the network address for retrieval, into the
  67.    directory. He currently has RFCs and FYI documents in, but would
  68.    like to move on to other internet archives.  He concluded that he
  69.    needed a more sophisticated approach. It was difficult to
  70.    characterize arbitrary archives, with too little information about
  71.    them. (See IAFA WG[5]).
  72.    
  73.  
  74. The World-Wide Web
  75.  
  76.    Tim Berners-Lee presented the World Wide Web (w3) and discussed
  77.    requirements for interworking between the systems.  The W3 project
  78.    was initially funded to provide an information infrastructure to
  79.    the world-wide community of high energy physicists.  The data
  80.    model is of documents which are hypertext and/or searchable
  81.    indexes.  The philosophy behind it is that a user should be able
  82.    to point and click on phrase or a word within a document and the
  83.    associated document would be retrieved from wherever in the world
  84.    and presented to the user in an appropriate format - without the
  85.    user having to be aware of where the document is located or what
  86.    the access method is.  These details are hidden in the hypertext
  87.    links.  There were server programs for many information servers,
  88.    gateways to WAIS, Archie and gopher and client programs for
  89.    various user machines.
  90.    
  91.  
  92.    The W3 clients use several protocols for accessing documents (FTP,
  93.    NNTP, WAIS, Gopher, and W3's own "HTTP") although this is hidden
  94.    from the user. The HTTP protocol is a simple stateless
  95.    search/retrieve protocol running over TCP.  As originally
  96.    conceived but not yet implemented, it included authentication and
  97.    data format negotiation.Tim discussed the differences between WWW,
  98.    WAIS, Archie, Gopher and Prospero systems.
  99.    
  100.  
  101.    The need for a  Universal Document Identifier (UDI) for describing
  102.    the address or, given a directory, name, for a document whatever
  103.    is access protocol was discussed, as outlined in OSI-DS-XX.  Each
  104.    application  uses a "handle" for a file which can be prefixed by
  105.    the particular protocol name to generate a universal address.
  106.    
  107.  
  108.    Most systems (WAIS excepted) are extensible, entertaining document
  109.    addresses which refer to other systems.  WAIS indexes currently
  110.    can only refer to documents in the same database, let alone with
  111.    other retrieval methods. There is a need for WAIS to be more
  112.    flexible. John Curran said he would bring this to the attention of
  113.    the WAIS community.
  114.    
  115.  
  116.    Addresses would not in the long term be suitable for references to
  117.    documents, so it was hoped that some sort of directory service,
  118.    operating within the UDI framework, would be incorporated.
  119.    
  120.  
  121.    More information:    telnet info.cern.ch.   Client and server code
  122.    is available by anonymous FTP from info.cern.ch.
  123.    
  124.  
  125.    Mailing lists:  www-talk@info.cern.ch, www-interest@info.cern.ch
  126.    
  127.  
  128.    Discussion document:   OSI-DS-29[6]
  129.    
  130.  
  131. Representing the Real World in the Directory
  132.  
  133.    Paper: OSI-DS-25[7]Steve Kille discussed this paper "Representing
  134.    the Real World in an X.500 Directory".
  135.    
  136.  
  137.    A Listing Service may be used to group like information items
  138.    together for example to provide a Yellow Pages Service.
  139.    
  140.  
  141.    Such a service could for example provide for members of a special
  142.    interest group, or could group documents on a particular
  143.    subject.Services such as Archie could be considered to be Listing
  144.    Services. One imagines an information Universe in which
  145.    Information Brokers provide different subject based (say) views
  146.    via their listing service. One would then need to locate the
  147.    various listing services (using a mechanism such as a directory?)
  148.    
  149.  
  150. UK British Library Project
  151.  
  152.    Paul Barker described a project, sponsored by the British Library,
  153.    to represent grey literature (unpublished research papers) in the
  154.    Directory.  The project is thought to be unlikely to succeed - but
  155.    one of the aims is to demonstrate whether or not it is possible.
  156.    They will take the (UK) MARC records and model these within X.500.
  157.     They might also consider trying to provide a listing service so
  158.    that the documents might be retrieved more readily by subject
  159.    area.
  160.    
  161.  
  162. Prospero
  163.  
  164.    Cliff Neuman described Prospero.  It follows a file system model,
  165.    rather than the hypertext model.  It is built on UDP for speed.
  166.    It has the notion of a Directory which contains links to other
  167.    objects (other directories or files).  It returns the link to the
  168.    information object and then automatically retrieves the file by
  169.    another mechanism by the appropriate access method (Archie, WAIS,
  170.    nntp, WWW - soon!, NFS, ftp etc.) It has been used very
  171.    successfully to access the archie database.
  172.    
  173.  
  174.    Cliff stated that he expected to be able to use X.500 to translate
  175.    between the document ID and how to get the document.
  176.    
  177.  
  178.    With Prospero the user has his own view of the global information
  179.    base (or has a view built for him).  Cliff thought there should be
  180.    multiple name spaces - but the difficulty would be that these
  181.    would need representing near the top of the directory tree.  With
  182.    multiple user chosen views - this would be difficult to manage.
  183.    Also two users might refer to an object by different handles which
  184.    would be relative to their individual name spaces - difficult when
  185.    passing references (say in a mail message) from one person to the
  186.    other.
  187.    
  188.  
  189.    The concept of "Closure":  Each object has a related name space.
  190.    All references within the object are resolved using the context of
  191.    the name space. Name spaces themselves have global network
  192.    addresses, but the user doesn't see that.
  193.    
  194.  
  195.    More information:  info-prospero@isi.edu
  196.    
  197.  
  198.  
  199. System 33
  200.  
  201.    Larry Masinter talked about a project at Xerox PARC. This has the
  202.    concepts:
  203.    
  204.  
  205.   HANDLE                 32 byte number (is a content ID). In fact
  206.                          this contains hints for finding the
  207.                          document.
  208.                          
  209.  
  210.   FILE Location  (6 part)
  211.                           Protocol; Host; Path; piece; format;
  212.                          timeout
  213.                          
  214.  
  215.   Description             (normal "Catalogue" information: Name,
  216.                          Author, etc)
  217.                          
  218.  
  219.    There is format negotiation when a document is retrieved. It is
  220.    not simple in reality to categorize data formats as there is such
  221.    a plethora of different varieties.
  222.    
  223.  
  224.    Gateways provide access between systems not sharing transport
  225.    protocols.
  226.    
  227.  
  228.    Also considered Access Control.  ACL is part of description.  The
  229.    Server exploits multiple protocols for Search and retrieve.
  230.    
  231.  
  232.    There is a problem with dealing with different types of document
  233.    (applications for jobs, product specs, memos, contracts, faxes,
  234.    etc. ) It is difficult to normalize the attributes of a general
  235.    document.
  236.    
  237.  
  238. Summing up
  239.  
  240.    Tim Berners-Lee summed up by saying that all applications
  241.    described used resolvable document address, and so for
  242.    interworking, we need a universal representation for such a
  243.    network object address. With the coming of  directories, names
  244.    should increasingly be used in place of network addresses. The
  245.    Universal Document Identifier was intended to be able to hold
  246.    either an name or address for any access protocol.  (This is not
  247.    the same as "USDN" a document serial  number which is not
  248.    resolvable, but only one of which exists for each document).
  249.    
  250.  
  251.     In discussion, Steve Kille suggested should be a WG on details of
  252.    UDIs  and a separate one for USDN.  A comment was that the W3 data
  253.    model encompasses those of the other systems.    John Curran
  254.    insisted on a better term than "UDI", suggesting "Document Access
  255.    Token".
  256.    
  257.  
  258.    Peter Deutch's need for a USDN is to be able to determine the
  259.    equivalence of two USDN. Chris Weider agreed to co-author a
  260.    document on the issues. Jill Foster suggested a pilotproject to
  261.    put UDI's in the directory for a set of documents and to have the
  262.    gopher, Prospero, archie, and Prospero people try to utilise
  263.    these.
  264.  
  265.    [These minutes have been largely built from Jill Foster's
  266.    report[8] and Karen Sollins' notes[9] for which I am most
  267.    grateful, though errors in the above are probably mine. Tim
  268.    BL]
  269.  
  270.  
  271.  
  272.      References:
  273.  
  274. [1]http://info.cern.ch/hypertext/Conferences/IETF92/IETF-9203.html
  275. [2]http://info.cern.ch/hypertext/Conferences/IETF92/LivingDocuments.h 
  276. tml
  277. [3]http://info.cern.ch/hypertext/WWW/Administration/Mailing/ietf-wwx- 
  278. bof
  279. [4]file://cs.ucl.ac.uk/osi-ds/osi-ds-22-00.txt
  280. [5]http://info.cern.ch/hypertext/Conferences/IETF92/IAFA-BOF.html
  281. [6]file://cs.ucl.ac.uk/osi-ds/osi-ds-29-00.txt
  282. [7]file://cs.ucl.ac.uk/osi-ds/osi-ds-25-00.txt
  283. [8]http://info.cern.ch/hypertext/Conferences/IETF92/WWX_BOF.html
  284. [9]http://info.cern.ch/hypertext/Conferences/IETF92/WWX_BOF_Sollins.h 
  285. tml
  286.  
  287.